In order to properly evaluate the test effort in an application development project, Project Managers and Business Managers must make estimates of person hours or days that will be required in the test effort. As test effort is a compromise between delay and quality, it is all the more important to define the right balance between those two parameters. In the last ten years, the test percentage in development projects has more than doubled. As a result, more and more projects are not implemented. Many of tools have been issued on the subject, but focusing more on application integration, when the problem is not only focused on the application, but on the global system where the application is to be integrated.
Conventional solutions to test effort estimation are based on development effort (estimation in hours or function points). To illustrate such an approach, an article from K. Bassin et al. entitled “Metrics to evaluate vendor-developed software based on test case execution results”, in IBM Systems Journal, Vol. 41, No. 1, 2002 describes an approach centered on the application, which is not an End-to-End approach of business flow cross applications. The limitation of this approach is that it does not enable a customer to measure business risks. And this prevents a customer business from having a focus vision of Information Technology (IT).
None of the known solutions are based on a functional risk analysis. However, this approach is key nowadays to avoid spending time on mathematical occurrences, that are ever increasing, due to applications interphasing with multiple other applications, these occurrences being far from used on the business side. Since today's systems are more and more open and communicating with other multi-technologies systems, logical occurrences are now gigantic. The only way to define efficiently the test effort is thus to focus on the functional business flows, and define with the customer, based on business risks, where to put the test focus. The effort of development is no longer the only metric to evaluate testing effort.
Another limit to actual approaches, is that these are developed for technologies and development languages, whereas nowadays business scenarios are based on several applications which are cross-technologies.
There is a need for a consistent evaluating approach for global test effort, based on functional tests, that works with cross-technologies and enables a first hand sizing.
The present invention offers a solution concentrated on business usage, and consequent business risks, whatever the technology supporting the scenarios.